🕸️ Ada Research Browser

tasks.md
Home›Research Reports›tasks.md
← Back

Tasks: Cloud Snapshot Demo Lifecycle

Input: Design documents from /specs/008-cloud-snapshot-lifecycle/ Prerequisites: plan.md (required), spec.md (required for user stories), research.md, data-model.md, contracts/

Tests: No test tasks generated (manual end-to-end testing against live Hetzner Cloud; follows existing project pattern for infrastructure scripts).

Organization: Tasks are grouped by user story. Note that the implementation order differs from spec priority order because US3 (Health Check) is a foundational dependency for US1 (Warm Start) and US2 (Snapshot Create).

Format: [ID] [P?] [Story] Description

Phase 1: Setup (Shared Infrastructure)

Purpose: Project initialization, Makefile targets, gitignore updates, and script skeletons

Phase 2: Foundational (Blocking Prerequisites)

Purpose: Post-restore playbook and shared helper patterns that MUST be complete before user story scripts

CRITICAL: US1 (Warm Start) depends on the post-restore playbook and inventory generation. Build these first.

Checkpoint: Foundation ready — user story implementation can begin

Phase 3: User Story 3 — Health Check a Running Cluster (Priority: P1)

Goal: Standalone health check script that SSHs into each node, verifies critical services, attempts auto-remediation on failure, and outputs a structured pass/fail summary table.

Independent Test: Run make demo-health against any running cluster (cold-built or snapshot-restored) and verify the summary table shows pass/fail for every service on every node. Exit code 0 when all pass, non-zero when any fail.

Implementation for User Story 3

Checkpoint: make demo-health works against any running cluster, reports per-service status, auto-remediates transient failures

Phase 4: User Story 2 — Create Snapshot Set from Running Cluster (Priority: P1)

Goal: Snapshot all 4 VMs as a labeled set with service stop/restart for consistency, write metadata to local manifest file.

Independent Test: After make demo-cloud-up, run make demo-snapshot. Verify 4 snapshots appear in Hetzner console with correct labels. Verify snapshot-manifest.json contains the new set entry.

Implementation for User Story 2

Checkpoint: make demo-snapshot creates a labeled snapshot set from a running cluster, services stop/restart cleanly, manifest file is written

Phase 5: User Story 1 — Warm Start a Demo Cluster from Snapshots (Priority: P1) MVP

Goal: Restore a complete 4-node cluster from snapshots in under 5 minutes with network configuration, hostname fixup, and health verification.

Independent Test: With a snapshot set available, run make demo-warm. Verify 4 VMs created, private network configured with correct IPs, health check passes, and existing demo scenarios run unchanged.

Implementation for User Story 1

Checkpoint: make demo-warm restores a full cluster from snapshots in under 5 minutes. Health check passes. Demo scenarios A-D run unchanged on the restored cluster.

Phase 6: User Story 4 — Graceful Session Wind-Down (Priority: P2)

Goal: Clean shutdown with optional pre-teardown snapshot, label-based resource destruction, session cost reporting.

Independent Test: With a running cluster, run make demo-cool. Verify snapshot prompt appears, teardown destroys all resources (zero orphans in Hetzner console), session summary displays duration and cost.

Implementation for User Story 4

Checkpoint: make demo-cool cleanly winds down a session with optional snapshot and cost summary

Phase 7: User Story 5 — Manage Snapshot Sets (Priority: P2)

Goal: List available snapshot sets with metadata and delete old sets to control costs.

Independent Test: Create multiple snapshot sets, run demo-cloud-snapshot.sh --list to verify tabular output, run demo-cloud-snapshot.sh --delete <label> to verify removal from both Hetzner and manifest.

Implementation for User Story 5

Checkpoint: Snapshot lifecycle is fully manageable — create, list, delete all work

Phase 8: Polish & Cross-Cutting Concerns

Purpose: Integration with existing cold-build workflow, end-to-end validation

Dependencies & Execution Order

Phase Dependencies

User Story Dependencies

US3 (Health Check) ──┬──→ US2 (Snapshot Create) ──┬──→ US1 (Warm Start) ──→ US4 (Wind-Down)
                     │                             │
                     └─────────────────────────────┘
                                                   └──→ US5 (Manage Snapshots)

Within Each User Story

Parallel Opportunities

Within Setup (Phase 1):

T002 (Makefile) + T003 (script shells) — different files, no dependencies

Within Foundational (Phase 2):

T005 (shared helpers) + T006 (inventory generator) — different functions, different scripts

Within US3 (Phase 3):

T007 (inventory parsing) + T008 (service checks) + T009 (mount/enrollment checks) — same file but independent functions

After US2 completes:

US1 (Warm Start) can proceed
US4 (Wind-Down) + US5 (Manage Snapshots) can proceed in parallel

Implementation Strategy

MVP First (Health Check + Snapshot Create + Warm Start)

  1. Complete Phase 1: Setup (T001-T003)
  2. Complete Phase 2: Foundational (T004-T006)
  3. Complete Phase 3: US3 Health Check (T007-T012)
  4. Complete Phase 4: US2 Snapshot Create (T013-T018)
  5. Complete Phase 5: US1 Warm Start (T019-T027)
  6. STOP and VALIDATE: Run end-to-end: make demo-cloud-up → make demo-snapshot → make demo-cloud-down → make demo-warm → make demo-health
  7. This is the MVP — you can now demo from snapshots

Incremental Delivery

  1. Complete MVP (Phases 1-5) → Fast demos work
  2. Add US4 Wind-Down (Phase 6) → Clean session lifecycle
  3. Add US5 Manage Snapshots (Phase 7) → Cost housekeeping
  4. Polish (Phase 8) → Integrated cold-build prompt, validation

Notes